Trendmicro smaschera per una seconda volta l’organizzazione criminale TeamTNT.
Il report pubblicato dalla società di sicurezza, conferma di aver trovato una seconda versione della botnet, più potente e raffinata. Se una prima versione del malware colpiva solo Docker ora è in grado di colpire anche i server di AWS.
Gli sviluppatori TeamTNT non sono più interessati solo al mining, ma ora gli script dannosi vengono sviluppati per rubare dati come credenziali e password. Inoltre la nuova versione del botnet è in grado di preparare l’ambiente per assicurarsi che abbia risorse sufficienti per minare la sicurezza di altre piattaforme, in effetti si nascondono nel sistema e installano anche backdoor nel caso in cui debbano connettersi da remoto ai server infetti.
Cosa succede? TeamTNT accede ai container Docker esposti, installando un malware di cripot mining, e ruba le credenziali per i server di AWS al fine di pivot su altri sistemi IT di un’azienda per infettare ancora di più server e distribuire miner di criptovalute. Questo tipo di attacco è pericoloso per le aziende che sono esposte online e anche per quelle che utilizzano API di gestione Docker. A questo punto una domanda sorge spontanea, è davvero possibile subire un simile attacco? Come è possibile lasciare spazio e dare libero accesso ai container?
La risposta è legata ad una delle seguenti alternative:
- Bug dell’applicativo, o di altri pezzi software contenuti nel container;
- API di Docker esposte a tutti;
- Repository Git non protetti, o protetti male (credenziali finite pubbliche, ecc.);
- Eventuali DB usati dall’applicativo esposti su internet.
Per non cadere nell’errore ed evitare che di esporsi a rischi di questo tipo, abbiamo stilato una lista di Best Practices da mettere in atto per proteggere i clienti da un eventuale attacco malware:
- Utilizzo di IAM Roles invece di utilizzare chiavi programmatiche come Access Key e Secret Access per le chiamate autenticate a servizi AWS
- Organizzazione networking con subnet pubbliche/private per proteggere i nodi “master” se utilizzato EKS o non esporre le EC2 in caso di ECS su EC2
- Avere un unico punto di accesso all’infrastruttura (come CDN) che sarà protetto poi con Web Application Firewall (WAF) per evitare attacchi di tipo DDoS, XSS, SQL Injection (protezione a livello 7 pila ISO/OSI) e protezione a livello 3-4.
- Utilizzo sempre di repository private (Code Commit/git/ecr)
- Non esporre credenziali applicative nei repository ma con altre soluzioni, come Bucket S3 locked da policy stringenti, AWS System Manager.
Inoltre bisogna ricordare che tutte le chiamate a servizi AWS richiedono un’autenticazione, anche via API e che AWS di default non espone nulla su internet.
Ecco due casi studio reali sui quali VMEngine è riuscita a impostare al meglio tutte le policy di sicurezza andando ad incidere positivamente sulle prestazioni e rendendo l’architettura IT protetta e scalabile: